Some additions and changes have been made to the software in this development package. The following list describes these changes along with some information on using the Thread Manager.
1) The big change: The Thread Manager has been updated to version 1.2. This release is both a bug fix release and an API enhancement release.
--> Two problems were found which we feel required us to release this version as quickly as possible. The first problem was with the main thread and event handling. The documentation states that the main thread will be forced to run if kNoThreadID was passed in by some yield call as the next thread to run, and an event is pending. The problem was that we would run the main thread EVERY time the above condition was true, rather than every OTHER time the condition was true. This caused all other cooperative threads to starve when an event was pending and the main thread did not handle it. The second problem was a Memory Manager incompatibility which has been fixed. The symptom was a trashed heap when a cooperative thread (other than the main thread) allocate memory and got a memFullErr from the Memory Manager.
--> The API additions are based around better thread pool management. A new gestalt bit was added to identify Thread Manager 1.2 as having enhanced thread pool support. A new thread creation option allows the caller of NewThread to choose 'equal fit' stack size for thread allocation from the thread pool. A new call GetSpecificFreeThreadCount, returns back the number of threads in the thread pool of the specified type and stack size.
2) The source level debugger, VoodooMonkey has been updated to version d20.
3) A bug was found with the ThreadUtils package, and is fixed in this version. From the author: "The bug is in ThreadUtil.c where I wasn't initializing the busy flag for a LinkedList Semaphore. This is now fixed, don't ask how it sometimes worked before, just the same ole voodoo magic! You don't have to recompile the ThreadUtilLib.o because I have enclosed one too. Don't inner the Utilities Read Me either, it has some other useful information."
4) There is a bug in the Traffic Simulation sample application with regard to custom context switchers. The custom context switchers in the application assume that register A5 points to the application globals, when in fact, it is not guaranteed to. The author of this application has been publicly chastised for not following the Thread Manager documentation about custom context switchers and A5. The fix to the code is left as an exercise for the reader.
5) General Thread Manager information:
-- The caller of DisposeThread can decide of the thread is reclaimed in the thread pool. If the thread calling DisposeThread is a preemptive thread, the disposed of thread is ALWAYS reclaimed in the thread pool to prevent Memory Manager calls from being called at preemptive thread time. When a thread RTSes, it will not be reclaimed into the thread pool unless it is a preemptive thread (for the above reason).
-- Thread termination routines can rely on register A5 being valid when they are called. Thread termination routines can make all the thread calls a thread can make. The thread result is set before the thread termination routine is run.
-- For those of you who use SIOW applications, you need to preload/lock all your code resources for the application to run correctly. No details on why this overkill is needed, but if you do this, it works.
-- A ThreadTaskRef is unique for each application launched and does not change during application execution.
-- Allocation from a thread pool works as 'best fit' for the new thread stack size unless the new thread creation option, kExactMatchThread, is used.
If you have any bug reports or comments, please don’t hesitate to link or write. You can contact us through the following:
AppleLink: ERIC3
or place your comments in the Developer Talk bulletin boards on AppleLink, the internet, Compuserve, AOL, or some other public discussion area.
